FZ-112 meeting type/category dictionary, some fixes to old migrations #161
Conversation
TPReal
force-pushed
the
develop
branch
2 times, most recently
from
d2a3fc6
to
ccecccb
Compare
There was a problem hiding this comment.
Czy tu z jakiegoś konkretnego powodu zostawiłeś insert i insertOrIgnore? Jeśli nie to pewnie też warto zmienić.
| { | ||
| $this->down(); | ||
|
|
||
| $date = '2023-11-02 00:00:00'; |
There was a problem hiding this comment.
W sumie tej daty nie musimy hardkodować, można użyć obecnego czasu.
There was a problem hiding this comment.
właśnie sam nie wiem, ten wiersz w bazie jakby pochodzi z czasu kiedy tworzyłem migrację, a nie z czasu kiedy została wykonana
There was a problem hiding this comment.
Z drugiej strony jak się setupuje bazę dla klienta, to czemu mają w niej istnieć wiersze "stworzone" przed datą tego setupu. Ale nie będę się kłócił - tylko wtedy pewni warto poprawić w mojej ostatniej migracji, bo tam użyłem now.
| */ | ||
| public function up(): void | ||
| { | ||
| $this->down(); |
There was a problem hiding this comment.
Właściwie z upsertem to jest zbędne, chyba że uznajesz że będą jakieś customowe pozycje już w bazie, wtedy down je wyczyści (no ale z drugiej strony ich nie oddtworzymy, więc pewnie nie powinno się to wykonać na już żyjącej bazie tak czy siak).
zaproponowane przeze mnie ostatnio
insertOrIgnoreignoruje wszystkie możliwe błędy,upsertrobi bardziej to co potrzebazmieniłem daty w starych migracjach gdzie mi się rok pomylił (2022 :D), a zahardkodowałem
no i 2 nowe słowniki, tylko że typ i kategoria nie są połączone ze sobą, bedą połączone przez
attributes